Review: The Wilding, by C.S. Friedman

Series:	In Conquest Born #2
Publisher:	DAW
Copyright:	2004
Printing:	July 2005
ISBN:	0-7564-0202-6
Format:	Mass market
Pages:	551

In Conquest Born is a rather odd space opera, featuring an interstellar war between two great empires that culminates in an intensely personal struggle between leaders of the two sides. It has one of the most intensely misogynistic societies in science fiction (the villains, yes, but weirdly ambiguous villains), genetic breeding programs for telepaths, and a host of unlikable but oddly fascinating characters. I thought it was weaker on re-read than I remembered it being originally, but it's still singular enough in memory that I wanted to read the sequel. The Wilding picks up in the same universe a century and a half later. I expected more of a direct connection to the plot of In Conquest Born, but I think this book could be read on its own. (This is good, given how the plot of In Conquest Born tends to slip out of my memory, despite how unique the book is.) The Azeans and the Braxins are, of course, still at war, an on-again, off-again affair that neither side seems likely to ever win. But the Azeans have forbidden psychic powers and driven all psychics underground, if they still exist at all. They are supposedly too unstable to be allowed in the carefully constructed Azean society. Tathas is Braxin, but not from the ruling Braxan tribe. He is caught practicing old rituals of his native tribe and escapes sentence of death by going on the Wilding, an ancient practice of leaving Braxin culture to find new genetic material and bring it back to strengthen their species. Or, put in less euphemistic terms, to find and rape a woman and bring back the resulting child, although apparently retrieving a genetic sample would also work. Did I mention the misogynistic society part? Still there. Zara, the other primary protagonist, is an Azean mediator who, as the book is opening, starts developing psychic powers. This is a rather serious problem that gets her suspended from her job. Her check of her own genetic records (the old-school SF obsession with eugenics is also still there) leads to the discovery that she's an identical twin, whose sister was kidnapped as an infant under mysterious circumstances and apparently by underground psychics. Zara decides to go in search of her. As with In Conquest Born, this book is full of deeply unpleasant societies and world views. Also as with In Conquest Born, I don't think Friedman intends any of them to be held up as examples of correct politics or behavior. What makes both of these books unusual is that neither she nor the characters seem to be making any attempt to construct a third alternative that would be better. The secret society of psychics has a different appeal, but it's not clear the characters would want to be part of it either, and it's quite possible that they're still responsible for a lot of the crap that's going on in the galaxy. The book feels like it ought to be political, as these societies are clearly broken and deeply abusive (the Braxins more obviously than the Azeans, but they're both creepy), but it mostly isn't. Instead, The Wilding is focused on individual people trying to make their way in this world. Those people come from varying strata of these societies. Zara and Tathas are there throughout; other characters crop up briefly with their own viewpoints and then often go away again or are killed. I think Friedman is going for a story of raw emotion and a tight focus on individual actions, with little in the way of clean morality or broader morals. And yet... the final act of the protagonists in the book is a political act that seems aimed at making the universe a better place. In a way, this is a very cynical book: there is a tremendous amount of manipulation and political maneuvering, and it's hard to see any cause here that one can fully support. This is all rather similar to In Conquest Born, but what held the previous book together was its backbone of obsessive vengeance and the spectacle of two intelligent people from utterly different societies locked in all-out emotional and physical combat. The Wilding doesn't have that. It has characters with strong motives and strong emotions, but none of them are the sort of epic, transcendent emotions that propel mythic heroes at each other. This is a more prosaic and personal book, which means the drama isn't strong and sweeping enough to make the reader forget the deep unpleasantness that's going on around them. The Wilding feels less like a clash of titans and more like personal quests for identity against a universe full of awful people and worse systems. It also retains, in the Braxin, aggressive male-dominant sexuality just this side of a Gor novel, but here that feels seedier and even more squirm-inducing than it did in In Conquest Born. The Wilding is even more ambiguous about the ethics of that sexual and misogynistic abusiveness; Tathas partly gives it up, but this is presented more as an accommodation to another culture than as a real engagement with the inherent abusiveness of Braxin society. I still have no idea whether and to whom I would recommend In Conquest Born. I'm less torn about The Wilding: don't bother. It's a lesser work in all respects, it shares some of the problems with too many characters and an occasionally incoherent plot, and I had even more trouble with the horrible societies Friedman creates than I did in the previous book. And it doesn't have the same counterbalance of epic, uncontrolled emotions and characters who seem to transcend the story they're in. Instead, it feels more like a story of damaged people in an awful universe who are meddling through as best they can while being manipulated by the people with real power. It got more depressing the more I thought about it, and the ending doesn't salvage the story. Rating: 4 out of 10

When I gave my Haskell Bytes talk on the runtime representation of Haskell values the first time, I wrote here It is in German, so [..] if you want me to translate it, then (convince your professor or employer to) invite me to hold the talk again . This has just happened: I got to hold the talk as a Tech Talk at Galois in Portland, so now you can fetch the text also in English. Thanks to Jason for inviting me!
This was on my way to the Oregon Summer School on Programming Languages in Eugene, where I m right now enjoying the shade of a tree next to the campus. We ve got a relatively packed program with lectures on dependent types, categorical logic and other stuff, and more student talks in the evening (which unfortunately always collide with the open board game evenings at the local board game store). So at least we started to have a round of diplomacy, where I am about to be crushed from four sides at once. (And no, I don t think that this has triggered the illegal download warning that the University of Oregon received about our internet use and threatens our internet connectivity.)

Cupt 2.6 is released to Debian unstable. Some prominent changes, citing from NEWS-file:

• Subcommands 'markauto' and 'unmarkauto' are now first-class management actions: can cause more actions in the same run (usually auto-removals) and
  have positional counterparts '--markauto' and '--unmarkauto'.


• New options '--asauto=yes', '--asauto=no' and '--asauto=default' to control whether packages, (directly) installed by some management action, should be marked automatically or manually installed.


• New choice 'rc' (show reason chain) in the actions preview prompt.


• New options '--select=traditional' and '--select=flexible' to control how many versions of packages are chosen for management actions.


• New options '--must', '--try', '--wish' and '--importance=' to control management requests' importance, allowing specifying optional requests and
  their priority.


• New 'functional selectors' ("FSE") syntax for advanced version selection in any subcommands which accept binary/source version expressions. The
  subcommand 'search' got a new option --fse.


• New, enabled by default, possibility to generate and use index-of-index files to speed up building the package cache.


• General support for "[ key=value... ]" option syntax in sources.list. Specific support for 'trusted=yes' and 'trusted=no' options.


• Apply id version suffixes (^) to version strings to differentiate versions with same version string but different/uncomparable hash sums, so no versions are skipped anymore.


• Support for 'InRelease' metadata files.


• Numerous improvements in speed and memory usage.


All new features, as usual, are introduced in the tutorial. Enjoy and send bug reports!

Just as last year, BalaBit applied to become a mentoring organisation for this year's Google Summer of Code, but like the year before, were not accepted. Instead, the openSUSE project was kind enough to give us two slots of their own, similarly to the year before - we are very thankful for this, and this year, both of the projects we took were closed successfully! So much so, that one of them was already merged into syslog-ng 3.5.0beta2, and the other one is being prepared for getting merged into the Incubator. I also helped out a little with Clojure & Leiningen packaging, although my contributions there were minimal at best.On the whole, I really liked this year's programme, our students accomplished a lot, and the whole summer was a great experience in itself, I learned a lot about mentoring, and about working with other people, people who are very new to the codebase they're working on. I would like to summarise what I learned and observed this year, in the hopes that others may find them useful too.This year, we set fairly ambitious goals for our students: they had to write a Redis and a MySQL destination, both of which presented interesting challenges to the students. None of them had prior experience with the syslog-ng source code, and their programming knowledge was mostly in C#, not plain old C which syslog-ng is written in. They also had to dabble a bit in the bowels of our overly complex configure.ac and a few Makefiles. Wasn't an easy task.In the beginning, we tasked the students to write proof of concept code, to get familiar with the libraries they will need to use - no syslog-ng involved at this point. This sounded like a good idea on paper, but without clear goals and milestones, a lot of time was spent on this task, and the students ran into a few dead-ends which could have been avoided, if we, the mentors, were more careful. This resulted in a reasonably poor first term, frustration and caused many a sleepless nights. We had to change our approach if we wanted to see the projects succeed.So we sat down with the students, and took one big leap: in person, we explained some of the internals of syslog-ng, did code reviews with them, and so on. But the best thing we did was what my colleague (and the main mentor), Viktor Tusa, came up with: we wrote a test script, that started syslog-ng, configured it, and ran tests against it. Students had to make their code pass the test by the next in-person meeting. This helped tremendously, and increased the speed they worked at by an order of magnitude at least. We kept developing the test script further, and so did the projects improve.ConclusionsThere are a couple of conclusions I arrived at as the programme concluded, things we (or other mentors, as I plan to participate as a student next year) will need to improve upon in the coming years.

• We need milestones at the time of announcing the project, not later, but by the time we put a project online, we need clear milestones.
• We need a way to help students track their own progress. We can't always be there for them, and that's OK. They need to be able to see how they're doing, though. Automated tests, whenever possible, are a great aid.
• In person meetings, with code reviews and explaining idiosyncrasies of the existing code-base are a great help to students, and also help us better understand how others would like to use our APIs, which in turn makes it easier to write APIs that are actually good.
• Lack of experience in the programming language is no big deal, experience can be gained during the programme, if the student is dedicated. We should not be afraid of involving smart, but less experienced students. As a consequence, requiring code samples may not be the best idea. That's a very high barrier to jump over. I would rather have a talk - in person, preferably - with the student, and see if they have the potential to bring the project to the finish line.
• We need to start preparing for next year soon, if we want to participate on our own. Can't wait for the last minute, starting just a month before the application period for organisations open is already too late.
• Involving the students in the project, letting them do useful work that gets merged during the programme is a huge accomplishment. Both our students expressed interest in not only participating next year too, but also continuing their work after GSoC. We need to keep this up in the coming years too!

The Sydney Users of R Forum (SURF) were kind enough to host me two days (well, three with the traveling ...) ago for an hour-long talk on Rcpp. Apparently, it set a new attendance record for this R user group. My thanks to Louise and Eugene for hosting a terrific meeting, and taking me out for a bite and drink afterwards. I have now put up my slides on my talks / presentations page for anyone else to peruse.

The Sydney Users of R Forum (SURF) will be hosting me for a talk on July 10. The focus will be Rcpp for R and C++ integration, and the intent is to have this be really applied with lots of motivating examples. Organizers Louise and Eugene were able to move this to a slightly larger room as the initial capacity of 50 was filled almost immediately. As of right now, the talk page shows a few available slots. If you're in the Sydney are in early July, why not register and swing by? If you're not in the area, the Rcpp Events page lists other upcoming talks too.

We are proud to announce that 16 students have been accepted to work on improving Debian this summer through the Google Summer of Code! This is great news, following our 15 accepted students in 2012, and 9 accepted students in 2011. Here is the list of accepted students and projects:

• Aarsh Shah: Improvements to Debian Search and the Search Interface
• Aron Xu: ZFS on Linux integration
• Boris Bobrov: Debian Metrics Portal
• Catalin Usurelu: Enabling free multimedia real-time communications (RTC) with Debian
• Eleanor Chen: MIPS N32/N64 ABI Port
• Emmanouil Kiagias: Redesign metapackage creation for Debian Blends
• Eugenio Cano-Manuel: Leiningen & Clojure packaging
• Fabian Gr nbichler: Add CROTP support to oath-toolkit and dynalogin
• Gustavo Alkmim: Bootstrappable Debian
• Justus Winter: Debian GNU/Hurd Debianish initialization
• Lei Wang: OpenRC init system in Debian
• L o Cavaill : scan-build on the Debian archive
• Marko Lalic: PTS rewrite in Django
• Pawel Sarbinowski: Debian Android Application
• Shuxiong Ye: OpenJDK and Debian
• Simon Chopin: Implementation of message passing in the Debian infrastructure

If you're interested in one of the projects, please follow the links and talk directly to the students or the mentors, or come hang out with us on IRC. Welcome everyone, and let's make sure we all have an amazing summer!

While release of Debian wheezy getting is closer and closer, Cupt's development version also moves forward bit by bit.

A couple of particularly interesting features -- showing full reason chains and functional selectors -- may be summarized by this screenshot.

And, as a fresh experiment, I placed a feature to widen functional selecting capabilities to Catincan, a (new?) crowdfunding platform for open source projects. Let's see how it goes.

Inspired by http://blog.zouish.org/posts/dpl_game/. The order is chosen by a fair dice roll.

Wouter Verhelst
Russ Allbery
Bill Allombert
Paul Wise

Some of my Romanian readers might know that for the last two years I've got involved in the skeptical movement to such a degree that I am a co-producer of a bi-weekly podcast on science and skepticism (in Romanian) called Skeptics in Romania . Some might even be regular listeners of the show.

(There isn't much to see now visually on the site, but me and the other people behind the project have some ongoing plans to change that.)

In spite of our modest site, up until now we had some successes, one of them being the publication of an article on us in a known Romanian printed publication and another being the invitation to a live show face to face with Oreste Teodorescu, a well known Romanian mysticist and woo promoter.

During that live show we managed to show a demonstration (video below, in Romanian) of how astrology gives the impression of working, without actually working, and, taking into account we had no prior TV camera experience and that it was a live show, I think we managed an honourable presence.


We also have a series of interviews in English with some really interesting people: Dr. Eugenie Scott, Prof. Christopher French, Prof. Edzard Ernst, Samantha Stein and others. We did these interviews at Denkfest 2011, in Zurich, and we integrated the translated (voice over) interviews in our podcast. The conlusion is that most of our activities revolve around the podcast, so let me tell you more about that.

The podcast has a somewhat fixed structure, it starts with a conversation between ourselves, then we have a segment on the history of science, technology, skepticism and woo, and then we have a segment called The dangers of not being skeptical . In this segment we present cases of people who lost their lives, their health, their money or any combination of the former because they were duped into some scam, science-y sounding non-science, unfounded claim or some other woo.

Having lost recently my brother-in-law to a form of cancer known as Hodgkin lymphoma, I became especially sensitive about miracle-cure claims for cancer, and this section of the show has lately seen its fair share of such cases. Honestly, if there could be a way to prosecute the irresponsible, ignorant and/or cynical people promoting all sorts of quack "therapies", especially for cancer*, I would really like to see it happen. But there isn't, and we're trying the best accessible approach, informing the public.

During my brother-in-law's last two years of his life, he went through lots of chemotherapy and radiotherapy sessions, repeated periods of hospitalisation, and lots of drugs. This is the best of what we currently have for treating and curing most forms of cancer, and too many times this isn't enough. I can't even imagine how stressful and discouraging it must feel when the best of what we have doesn't help.

Here is where the desperation and hopes of patients and their families meet the purely irresponsible cynical or ignorant promoters of woo and quack therapies. Because it takes either an ignorant or a really cynical (I really feel this word isn't enough) person to prey on the suffering of other people to make easy money under the false pretence of offering a cure.

It almost happened to my brother-in-law and his family, because they almost went for some herbal concoction promoted as a cancer cure on some forum, blog or page of a seller of this fake therapy. It was really hard for me to make them understand why using such a product it not advisable, not even in parallel with the medical treatment due its possible counter effect or interactions with the real medical treatment, without them getting the wrong idea that I wasn't trying to help. While trying to be brief and informative not to lose their attention, I told them how "natural" doesn't necessarily mean "good" (uranium, lead and Irukandji's venom are all natural), and how plants are drugs because they all contain chemical substances (and no, "chemical" does not mean "human made" or "artificial") which could interact with the medical treatment.


But most people don't even have the chance of having close by a person with a more science-leaning thought process and a skeptical mind. Those unfortunate people are the most vulnerable people and constitute the biggest chunk of the victims of baseless pseudo-cures or pseudo-treatments.

On our last show, I presented the case of Yvonne Main, a cancer suffering patient who mistook an invasive carcinoma for a cyst, and irdologist Ruth Nelson for a real healthcare giver.

Yvonne Main, died from an invasive carcinoma after seeking help from a iridologist, and delaying real medical treament for 18 months

Yvonne, after seeking medical advice from a person that essentially promotes the dead idea of guessing diseases by looking at the eyes**, used natural treatments for about 18 months and, after all this time, her carcinoma grew to a size of 10 to 11 cm, eating through her skull and causing damage which was later attempted to be countered through bone transplant from her ribs.

Ruth Nelson wasn't prosecuted in any way and continues her practice of quackery unharmed.

This is not the only case, nor even one case from a select few where woo and quackery lead to grave consequences for patients. There are many, many more; they're so many that even after splitting them in categories they seem too many per category, especially when you realise these are only the findings of, essentially, a single man:




This is part of what I have been doing in the last few years, instead of working on Debian. Is it a good thing? Is it a bad thing? Maybe it's good. I want to know what do you think?


* you will, most likely, never hear such a promoter of non-therapies say that there isn't just one cancer, and that, in fact, cancer is a name for a certain family of diseases which are all called cancer - that's a first sign that you might be dealing with quack
** probably in the line of thought that the eyes are the gates to the soul so they must tell something significant about health

A status update for what changed since Squeeze release and what is the state of Cupt in Wheezy. No new things for those few who follow small blog posts or the changelog, but an overview for, maybe, softly or newly interested.

Cupt, the high-level package manager for Debian with a console interface and therefore APT's competitor, continued its development since the first stable series. In the second major version it's rewritten in C++(11), got many new features such as numerous improvements in the depedency resolver and the dpkg action scheduler, the support of index diffs, the tutorial, wget-based download method, position action override options, logging, colored action preview prompt, treeish detailed error messages if no solutions were found, to name most important. That said, if you want multiarch, CDROM repository support or, say, some exotic download method, -- Cupt won't suit, at least for now. Project-wide support is also still almost completely missing as many developers accept no more than two package managers.

The "bug-freeness" aim still holds, at the moment of writing there is no unfixed runtime bugs of priority normal+. Here I thank again those people who reported bugs, you all definitely made Cupt better. I am sure there are bugs still which wait their time to show up, but that's hardly avoidable.

All in all, 2.x is a big step forward from 1.x. Not a last step -- development continues.

If you like me spent hours searching what does the rtmpdump's error (when trying to download live streams)

Caught signal: 13, cleaning up, just a second...

, following by

ERROR: WriteN, RTMP send error 32

mean, then after browsing many public sources (and finding no evidence there), measuring the connection throughtput (thanks to iftop program) and trying different internet providers I can, with a high level of confidence guess that error means

"your (average) connection speed is slower than what server expects, and your client is enough behind the stream that server has no more data for you"

Half a year since the last status update, so here we go:

• New mailing lists: cupt-user and cupt-devel, thanks to the Alioth people&infrastructure. The first, cupt-user is the preferred form of the feedback (except of the bug reports, which still go to the Debian BTS) from now on, also I intend send there announcements and questions to all users who care. The second, cupt-devel, is set as maintainer address for the Cupt package in Debian; also, as the name suggests, a place for discussions about the code if any.


• New versions: 2.3, 2.4 and 2.5 have been released bringing many new command line switches, an opt-in ANSI color support for the action preview prompt, improvements in the error and warning messages and more.


• Multiarch: Cupt in wheezy won't support multiarch. No standard is published yet and not enough time to test for a stable release. Once the standard is published, I plan (but don't promise) to set the branch in the repository and evaluate the implementation details.


• Localizations: the code and message strings seem now ready, and I'm going to send a call for translations in a week.

Suppose that you need to write an interface to a function which draws triangles. It could look like this: (the language is a C++-based pseudocode)

void rawDrawTriangle(size_t a, size_t b, size_t c)   ...  
bool isValidTriangle(size_t a, size_t b, size_t c)
 
  return (a + b > c) && (a + c > b) && (b + c > a);
 
void drawTriangle(size_t a, size_t b, size_t c)
 
  if (max(a, b, c) > MAX_LINE_LENGTH)
   
    throw("one of sides is too big");
   
  if (!isValidTriangle(a, b, c))
   
    throw("invalid triangle");
   
  rawDrawTriangle(a, b, c);
 
void userFunction()
 
  ...
  drawTriangle(3, 5, 7);
  ...
 

And the following is how a bureaucratic version of the code could look like:

class Certificate
 
  time_t getCreationTime() const   ...  
  Certificate()   ...  
 ;
class TriangleIsValidCertificate: public Certificate
 
 public:
  const size_t a;
  const size_t b;
  const size_t c;
 private:
  TriangleIsValidCertificate(size_t a, size_t b, size_t c)   ...  
 friend class TriangleCertificationAuthority;
 ;
class TriangleCertificationAuthority
 
  static TriangleIsValidCertificate getTriangleIsValidCertificate(size_t a, size_t b, size_t c)
   
    msleep(random() * 2);
    if ((a + b > c) && (a + c > b) && (b + c > a))
     
      if (a == b && a == c)
       
        msleep(random() * 10); // hm, suspicious query
       
      return TriangleIsValidCertificate(a, b, c);
     
    else
     
      throw("invalid triangle");
     
   
 ;
class LineIsDrawableCertificate: public Certificate
 
 public:
  const size_t length;
 private:
  LineIsDrawableCertificate(size_t l)   ...  
 friend class LineCertificationAuthority;
 ;
class LineCertificationAuthority
 
  static LineIsDrawableCertificate getLineIsDrawableCertificate(size_t length)
   
    msleep(rand());
    if (length <= MAX_LINE_LENGTH)
     
      return LineIsDrawableCertificate(length);
     
    else
     
      throw("the line is too long");
     
   
 ;
void drawTriangle(size_t a, size_t b, size_t c, LineIsDrawableCertificate lineCerts[3], TriangleIsValidCertificate tivCert)
 
  msleep(rand() * 5);
  if (lineCerts[0].length != a   lineCerts[1].length != b   lineCerts[2].length != c)
   
    throw("your application is rejected");
   
  if (tivCert.a != a   tivCert.b != b   tivCert.c != c)
   
    throw("your application is rejected");
   
  if (time() - tivCert.getCreationTime() > '60 milliseconds')
   
    throw("your application is rejected");
   
  msleep(rand());
  rawDrawTriangle(a, b, c);
 
void userFunction()
 
  ...
  size_t a = 3, b = 5, c = 7;
  auto aCert = LineCertificationAuthority::getLineIsDrawableCertificate(a);
  auto bCert = LineCertificationAuthority::getLineIsDrawableCertificate(b);
  auto cCert = LineCertificationAuthority::getLineIsDrawableCertificate(c);
  auto tviCert = TriangleCertificationAuthority::getTriangleIsValidCertificate(a, b, c);
  drawTriangle(a, b, c, array(aCert, bCert, cCert), tviCert);
  ...
 

Seems that Intel developers eventually created patch that solves the main issue with Zenbook under Linux.
With Eugeni Dodonov s patch I m finally able to use RC6 feature and have stable system with acceptable battery lifetime. Almost two days without sudden shutdown using that patch Happily there s chance that this patch is going to be included in 3.3.x mainline kernel. Beware that i915.i915_enable_rc6=1 kernel option means something different with patched and vanilla kernel.

I experienced situations of writing substantial amounts of code (feature branches) for hours, days and even weeks only to find later that the written code can be thrown to the bin, either because of hidden design problem(s) or too much negative implications outweighting the positive implications of the change.

After reading some recent multiarch threads on debian-devel@ and seeing what hacks are seriously being proposed to implement only to keep the thing going, I now think that the low-level part of the Debian multiarch implementation proposal is no less broken than its high-level part, and the whole proposal is a one big hack which requires and will require more subhacks. Some will benefit from the added functionality, but all, both maintainers and users will suffer from drawbacks.

How two paragraphs above are related? We still have the time to revert the changes and say "sorry, it was a nice idea but the software world isn't ready".

It took longer than usual, but I believe it's worth.

I just released Cupt 2.2.0~rc1 to Debian experimental. To experimental, because there are important changes and I would appreciate "in-field" testing before final 2.2.0.

Here are the major changes since 2.1.x:

• Dpkg action sequencer improvements. There are multiple improvements, both in quality and speed.


• Repository index deltas. Or, in APT terminology, "PDiffs". Finally, there is an initial support for them. They are switched on by default (if you have Recommends disabled, make sure you have 'ed' package installed). To switch off, set the option 'cupt::update::use-index-diffs' to 'no'.


• Action override options. New console front-end's options '--install', '--remove', '--purge', '--satisfy', '--unsatisfy' allow to mix any of corresponding actions to the single command. See the tutorial and the man page for examples and details.


• Logging. By default, system changes are now logged to /var/log/cupt.log. Refer to the tutorial section 'Logging' for tuning.

Enjoy and send the bug reports.

I released new major version of Cupt, 2.0.0 (== 2.0.0~rc2), today. The final list of major changes since 1.5.x is available here and in binary packages. A web copy of the (newly written) tutorial is here.

Thanks to all bug reporters who helped to make it better.

Packages have landed to Debian unstable and should be available on the mirrors soon.

Let's assume that all low-level and file-layout work is done, and we need specifications how to make Debian high-level package managers multi-arch aware.

What we have now: only one package of the same name can be installed in the system, and packages can declare dependencies only against packages of the same architecture.

What, hence, needs to be specified:
a) are certain packages of the same name but different arches co-installable or not;
b) allow to specify foreigh arches in dependencies.

Then, how our high-level multi-arch spec could be written?

a) new field 'MultiArchCoinstallable: yes' for co-installable packages;
b) new dependency syntax: package_name[:[!]arch[,arch]...], for example: 'perl' (assuming 'perl:native' for forward dependencies like 'Depends' or 'Recommends', and 'perl:any' for Conflicts and Breaks), 'perl:amd64', 'perl:amd64,i386', 'perl:!i386', 'perl:native', 'perl:any'.

That's all. Looks easy and mostly intuitive, doesn't it? However, some people are going to implement this instead.

Cupt v2 has reached a beta stage.

Main news of Cupt v2 comparing to Cupt v1 are grouped here.

Notable changes since 2.0.0~alpha3:

• New configurable score calculation system in the native resolver (new option group 'cupt::resolver::tune-score::*')
• Added an ability to specify additional package expressions and restart the solving process in the action preview prompt (new choice 'a')
• When no solutions were found, throw an error with a solution tree(s) to show why.
  Example:
  

  $ cupt-experimental -s -R remove kdepimlibs-kio-plugins kdebase-workspace+
  Building the package cache...
  Initializing package resolver and worker...
  Scheduling requested actions...
  Resolving possible unmet dependencies...
  E: unable to resolve dependencies, because of:
  plasma-widgets-workspace 4:4.4.5-8 depends on 'plasma-dataengines-workspace (= 4:4.4.5-8)' -> no solutions
    plasma-dataengines-workspace 4:4.4.4-1 depends on 'kdepim-runtime' -> removed plasma-dataengines-workspace
      kdepim-runtime 4:4.4.3-1 depends on 'kdepimlibs-kio-plugins' -> removed kdepim-runtime
    plasma-desktop 4:4.4.5-8 depends on 'plasma-widgets-workspace (= 4:4.4.5-8)' -> installed plasma-widgets-workspace 4:4.4.5-8
      kdebase-workspace-bin 4:4.4.5-8 depends on 'plasma-desktop (= 4:4.4.5-8)   plasma-netbook (= 4:4.4.5-8)' -> installed plasma-desktop 4:4.4.5-8
        kdebase-workspace 4:4.4.5-8 depends on 'kdebase-workspace-bin (>= 4:4.4.5-8)' -> installed kdebase-workspace-bin 4:4.4.5-8
  plasma-dataengines-workspace 4:4.4.5-8 depends on 'kdepim-runtime' -> no solutions
    kdepim-runtime 4:4.4.3-1 depends on 'kdepimlibs-kio-plugins' -> removed kdepim-runtime
    plasma-widgets-workspace 4:4.4.5-8 depends on 'plasma-dataengines-workspace (= 4:4.4.5-8)' -> installed plasma-dataengines-workspace 4:4.4.5-8
      plasma-netbook 4:4.4.5-8 depends on 'plasma-widgets-workspace (= 4:4.4.5-8)' -> installed plasma-widgets-workspace 4:4.4.5-8
        kdebase-workspace-bin 4:4.4.5-8 depends on 'plasma-desktop (= 4:4.4.5-8)   plasma-netbook (= 4:4.4.5-8)' -> installed plasma-netbook 4:4.4.5-8
          kdebase-workspace 4:4.4.5-8 depends on 'kdebase-workspace-bin (>= 4:4.4.5-8)' -> installed kdebase-workspace-bin 4:4.4.5-8
  E: error performing command 'remove'
  

Full changelog is available in debian/changelog, as usual.

binary packages for i386, source package and README